An identity management system is a system that manages digital identities, which are a collection of attributes and their values used to identify the entities of an IT system and make identity claims. Identity management includes entity creation (registration) and validation (binding of identity attributes to real-world entities), as well as storage, maintenance, updates, distribution, verification, use, and protection of identities. Identity attributes and their values, the so-called namespace, include named objects that represent real-world entities, such as countries, organizations, computers, applications, persons, and devices.
The attributes comprising digital identities are used by humans, computers, and digital devices to identify, recognize, and interact with other entities involved in the operation of an IT system. Use of identities allow a person or a computer to recognize entities involved in a session or transaction, i.e. associate digital identity with the real-world person, computer, or device and, based on that, to determine the role, profile, authorization, and scope of actions that an entity is authorized to perform. Because of all the services that an IDMS provides, the role of such a system in automated IT environments is extremely important. Specifically, (a) IDMS functions must be always performed correctly, (b) IDMS data management must be reliable and correct, and (c) IDMS resources (software and data) must be strongly protected against illegal or accidental modifications, deletions; and insertions.
At the time of this invention, most IDMS implementations are in the form of large, centralized database repositories located on large network or cloud servers. Although such solutions correctly perform their core functions, centralized database servers have, in principle, many serious problems. First, they represent single point of failure. Next, in addition to basic functionality, it is also important to maintain and guarantee the correctness, integrity, and continuous availability of data. In distributed, large-scale environments, the components and protocols for using them—federation—are very complicated. For an IDMS, its protection, authenticated access, secure administration, and authorized use are important considerations. Because identification data must be protected when transferred outside of the security perimeter, a centralized IDMS is very expensive to establish, maintain, operate, and protect. Finally, all participants in an IT system must place a high level of trust in the correct operation and accuracy of the data stored in, and distributed by, an IDMS.
In addition to problems due to the large size and centralized nature of such repositories, trust is required for IDMS functions that are provided by third-party solutions. To provide that trust, IDMS providers must guarantee the following features: (a) the protection and control of external access to IDMS repositories, (b) the internal protection of data stored in these repositories, (c) the elimination of impersonation by authorized administrators, (d) the security of all protocols and data, (e) the recovery of all lost, stolen, or destroyed data.
In addition to identifying system entities, the data stored in an IDMS are often also used for other security services, such as the authentication, authorization, management of secret keys, and others. At the time of this invention, the security services always required users' sensitive and secret data to be stored in IDMS repositories. This approach requires not only the strong protection of these security credentials, but also their correct use. All these aspects represent another group of important problems and weaknesses of centralized repositories that store and handle secret and sensitive user data.
If all these complex security aspects and arrangements are successfully resolved, then the attributes and functions of an IDMS may be used with full confidence for security services. However, in addition to security, at the time of this invention, two significant trends of increasing importance were user privacy and anonymity of their identity and transaction data. An IDMS that stores users' explicit identifying attributes and their sensitive security credentials cannot provide privacy and anonymity of users and their transactions. In addition, at the time of this invention, almost all IT application service providers collect personal and transaction data and use and share this data in unauthorized ways, without user consent, thus further violating user privacy and anonymity.
Based on all of these problems, it is obvious that it is important for identity management solutions to not use large directories or database repositories, to not require trust, to protect the data stored in repositories, and to allow users to prevent and control the use and sharing of their personal data.
At the time of this invention, there was an emerging concept with characteristics and features that seemed like a promising approach and technology to solve some, if not all, problems mentioned above. The concept has emerged from the Bitcoin peer-to-peer payment system and is called the distributed public ledger. In general, the ledger represents a public archive of the data and transactions that are performed in some data processing system. The concept is promising because (a) the data stored in a ledger are all public and therefore not vulnerable to theft, (b) the data are integrity-protected and therefore not vulnerable to illegal or accidental modifications, (c) the data are time-stamped, so their date/time of origin could be validated, and (d) the data are sequenced in a functional, cryptographic time “chain”, so illegal insertions of false data is impossible. These core features of public ledgers are very attractive solutions for the design, implementation, and operation of large-scale identity management systems that do not contain private and personal data and operate without the assistance of any third party and without the need to trust any component of the overall system.
The core idea and the main functionality of the public ledger introduced in the Bitcoin system is to enable a recipient of a peer-to-peer payment transaction to validate the correctness of the transaction without relying on a third party. For payments, validation includes the validation that a payer has sufficient amount of Bitcoins to make the transaction and proof that “double-spending” was not performed. For that, Bitcoin uses the approach to reconstruct the balance of the sender's wallet by the recipient. The recipient performs that by tracing all sender's transactions, from the first “coinbase” transaction up to the last transaction received by the sender. The construction of the blockchain, which contains cryptographically signed and mutually linked blocks of transactions, effectively prevents the illegal manipulation of transaction history and, in that way, guarantees to all participants the correctness of individual transactions.
The idea of using the original Bitcoin public ledger and blockchain, which are used for Bitcoin payment transactions, as the supporting technology and concept for some other type of applications generated many interesting ideas and initiatives. But, although attractive and interesting, careful analysis of the proposed solutions shows that they are all deficient, contradictory, infeasible, and inadequate; in essence, they do not offer the full functionality of an IDMS. The main reason for the difficulties in using the Bitcoin blockchain is that as a linked list of blocks of payment transactions, it is not suitable for use with identities. The identities of individual entities are not mutually functionally related, so they do not need to be linked to each other or packaged in Bitcoin blocks. They do not functionally depend on each other and do not have a dependency sequence; therefore, they do not need to be chained in the Bitcoin ledger. Another serious limitation is that when Bitcoin addresses, which are public cryptographic keys, are used as the identities of user accounts, they provide only and limited user anonymity and not user identification, authentication, or authorization. The anonymity of user identities is suitable for peer-to-peer payment transactions using Bitcoin, but not for many other types of applications and transactions, even with other types of virtual currencies. Bitcoin concept is also vulnerable to the theft of private keys, resulting in direct access to the users' Bitcoin wallets.
Furthermore, at the time of this invention, there are many operational issues when using the Bitcoin blockchain and its ledger for applications and transactions other than Bitcoin payments. The size of the blocks is too small, the throughput of the Bitcoin validation protocol is very low, the validation of blocks has long delays, the Bitcoin network is vulnerable to denial-of-service attacks, the protocol is vulnerable to timing attacks, and dishonest mining procedures and arrangements. Therefore, all the ideas that suggested using standard concept of the Bitcoin blockchain and public ledger to manage digital identities do not represent feasible and viable solutions. Furthermore, careful analysis of all existing solutions reveals that none perform IDMS protocols as pure peer-to-peer transactions; rather, each of them introduces some type of the third-party component that makes them, in essence, equivalent to large IDMS repositories.
One important problem with every IDMS, which solutions based on use of the Bitcoin blockchain and its public ledger did not solve, was binding of digital identities to the real-world entities that they identify. Some solutions that use the Bitcoin blockchain to store and distribute the hashes of user identities suggest using social websites as data sources for these identities. However, this method of validating identities, merely by the fact that they are included in a blockchain, is misleading because (a) the sources of these identities are unreliable and (b) their validation can be much better and more efficiently performed using original websites. The authors of these ideas incorrectly claim that by using Bitcoin blockchain, users would regain control of their personal information, which contradicts the nature of the blockchain as a public ledger where the stored identities may be accessed and used by anyone. In fact, the main weakness of this solution is that there is no personal protection of public data in a blockchain, which means that users still do not have control of the access and use of their data by other users and service providers.
One of the subtle problems of the simple approach of loading hashes of identities into a Bitcoin blockchain is the verification of the relationship of attribute values to real-world entities. Identities established without validation, using first-come, first-serve principle, are completely unreliable and therefore cannot be used for serious business applications. While Bitcoin payments are performed in a completely new system, one that is isolated from any other system and functionally independent of all other systems, identities and their data are not objects of that nature. Namely, any reliable and trusted IDMS must guarantee the correctness of its data and their reliable binding to real-world entities. In classical IDMS, that validation is performed by IDMS providers. Therefore, these properties can be achieved only by validating blockchain entries by trusted identity providers that are external to the blockchain IDMS. However, this approach is contrary to the very nature of the blockchain approach, as it depends on trusted third parties to validate identities.
Another important conceptual problem with solutions that rely on the Bitcoin concept, network, protocols, and messages is the fact that the Bitcoin system is not truly peer-to-peer system. It uses and depends on trusted third parties, which are network servers comprising the Bitcoin network. Not only must users trust these servers to perform efficiently and correctly their functions, what cannot be formally verified, but the network servers also control the overall system in terms of the difficulty of hashing, the timing of releasing of blocks, block sizes, and payout rewards. Another category of trusted third parties in the Bitcoin system is miners—persons who perform cryptographic operations on blocks of transactions to validate them. This clearly means that any IDMS that uses the services of the Bitcoin network is itself not reliable and depends on third-party components.
Another serious problem with the Bitcoin blockchain is the delay in validation of blocks and transactions. On average, it takes about 10 minutes; furthermore, transactions cannot be considered validated until they appear in the subsequent six/seven most recent blocks. This delay makes the use of such protocols completely unacceptable for many applications that need instantaneous validated transactions. A serious conceptual problem is that there may not be a hash for the block that corresponds to the given target. These reasons—slow progress, long reaction time, and the possibility that the progress of the blockchain may be blocked—also suggest the need for the new and innovative approach described in this invention.
Yet another important problem with all solutions that rely on the Bitcoin blockchain is that they do not provide the identification for real-world entities whose identities have been included in the blockchain when making identity claims. As mentioned earlier, identities must be used to recognize real-world entities. Inserting hashes and public keys into the Bitcoin blockchain merely proves the existence of the specific set of attributes and their values at the time when the hash is inserted and their binding to the corresponding public key. Thus, these attributes cannot be used to recognize a specific entity from the real-world, since it is impossible to reliably relate the attributes with the entity that these attributes describe and that owns the public key.
The final deficiency of solutions proposed at the time of this invention was that all of them, in addition to the Bitcoin network, also used a number of their own new servers. So, even if the Bitcoin network is only considered to be a distribution network, the proposed solutions do not perform pure peer-to-peer transactions. They introduce new servers as trusted third parties and new complex infrastructures, equivalent to the classical IDMS servers that the new solutions claim to improve. Some of these servers are used as intermediaries, some as external storage servers, and others for generating and handling protocol attributes.
In conclusion, the essence of the blockchain in the Bitcoin system is to make available and to guarantee the correctness of all transactions in the system and to provide the mechanisms to validate their correctness. Interpreting these two features formally and applying them to an IDMS leads to the conclusions that (a) the identities of individual entities can be included in the blockchain and thus be available to the entire community, and (b) identities and their blocks should be hashed and signed based on proof-of-work by miners, so that their content is guaranteed. However, such a formal approach has no significant advantages. First, the distribution of identities is not an essential problem for any IDMS. Second, integrity of attribute values can be guaranteed by using standard cryptographic algorithms. And third, miners cannot solve the key problem of any IDMS: binding of identity attributes to real-world persons. Therefore, an innovative solution must address and eliminate these issues and introduce additional features that offer clear benefits.
The system proposed in this invention performs its functions as truly peer-to-peer transactions without any third parties and without the requirement to place the trust in any component of the system. As such, the proposed system is an IDMS based on the concept of the public identities ledger. The resources of the system (identities) are strongly protected, maintained, and distributed only by consent of their owners. The system provides full security, privacy, and anonymity of user identities. Such an IDMS represents the backbone of an infrastructure supporting applications that require security, privacy, and anonymity for their users, transactions, and data.